Fixture-based test framework for Rust
Introduction
rstest
uses procedural macros to help you on writing
fixtures and table-based tests. To use it, add the
following lines to your Cargo.toml
file:
[]
= "0.23.0"
Features
async-timeout
:timeout
forasync
tests (Default enabled)crate-name
: Importrstest
package with different name (Default enabled)
Fixture
The core idea is that you can inject your test dependencies
by passing them as test arguments. In the following example,
a fixture
is defined and then used in two tests,
simply providing it as an argument:
use *;
Parametrize
You can also inject values in some other ways. For instance, you can
create a set of tests by simply providing the injected values for each
case: rstest
will generate an independent test for each case.
use rstest;
Running cargo test
in this case executes five tests:
; ; ; ;
If you need to just providing a bunch of values for which you
need to run your test, you can use #[values(list, of, values)]
argument attribute:
use rstest;
]
value:
)
Or create a matrix test by using list of values for some variables that will generate the cartesian product of all the values.
Use Parametrize definition in more tests
If you need to use a test list for more than one test you can use rstest_reuse
crate. With this helper crate you can define a template and use it everywhere.
use rstest;
use ;
See rstest_reuse
for more details.
Feature flagged cases
In case you want certain test cases to only be present if a certain feature is
enabled, use #[cfg_attr(feature = …, case(…))]
:
use rstest;
This also works with rstest_reuse
.
Magic Conversion
If you need a value where its type implement FromStr()
trait you can use a literal
string to build it:
# use rstest;
# use SocketAddr;
You can use this feature also in value list and in fixture default value.
Async
rstest
provides out of the box async
support. Just mark your
test function as async
, and it'll use #[async-std::test]
to
annotate it. This feature can be really useful to build async
parametric tests using a tidy syntax:
use *;
async
Currently, only async-std
is supported out of the box. But if you need to use
another runtime that provide its own test attribute (i.e. tokio::test
or
actix_rt::test
) you can use it in your async
test like described in
Inject Test Attribute.
To use this feature, you need to enable attributes
in the async-std
features list in your Cargo.toml
:
= { = "1.13", = ["attributes"] }
If your test input is an async value (fixture or test parameter) you can use #[future]
attribute to remove impl Future<Output = T>
boilerplate and just use T
:
use *;
async
async
As you noted you should .await
all future values and this sometimes can be really boring.
In this case you can use #[future(awt)]
to awaiting an input or annotating your function
with #[awt]
attributes to globally .await
all your future inputs. Previous code can be
simplified like follow:
use *;
#
# async
async
async
Files path as input arguments
If you need to create a test for each file in a given location you can use
#[files("glob path syntax")]
attribute to generate a test for each file that
satisfy the given glob path.
The default behavior is to ignore the files that start with "."
, but you can
modify this by use #[include_dot_files]
attribute. The files
attribute can be
used more than once on the same variable, and you can also create some custom
exclusion rules with the #[exclude("regex")]
attributes that filter out all
paths that verify the regular expression.
You can pass in environment variables by using ${ENV_VAR_NAME}
in the glob
path, e.g. #[files("${SOME_ENV}/hello")]
. To set a default value for the
environment variable, use ${ENV_VAR_NAME:-default_value}
.
Files are resolved at compile time against your Cargo project root
(the CARGO_MANIFEST_DIR
environment variable). If you need to change this
behavior, you can use the #[base_dir = "..."]
attribute to specify a different
base directory. That directory MUST exist, and will be used as the root for
the files, as well as to resolve the relative path when creating the test name.
Similar to the files
attribute, you can use ${ENV_VAR_NAME}
in the base_dir
.
Default timeout
You can set a default timeout for test using the RSTEST_TIMEOUT
environment variable.
The value is in seconds and is evaluated on test compile time.
Test #[timeout()]
You can define an execution timeout for your tests with #[timeout(<duration>)]
attribute. Timeout
works both for sync and async tests and is runtime agnostic. #[timeout(<duration>)]
take an
expression that should return a std::time::Duration
. Follow a simple async example:
use *;
use Duration;
async
async
In this case test pass because the delay is just 10 milliseconds and timeout is 80 milliseconds.
You can use timeout
attribute like any other attribute in your tests, and you can
override a group timeout with a case specific one. In the follow example we have
3 tests where first and third use 100 milliseconds but the second one use 10 milliseconds.
Another valuable point in this example is to use an expression to compute the
duration.
async
If you want to use timeout
for async
test you need to use async-timeout
feature (enabled by default).
Inject Test Attribute
If you would like to use another test
attribute for your test you can simply
indicate it in your test function's attributes. For instance if you want
to test some async function with use actix_rt::test
attribute you can just write:
use *;
use actix_rt;
use Future;
async
Just the attributes that ends with test
(last path segment) can be injected.
Use #[once]
Fixture
If you need to a fixture that should be initialized just once for all tests
you can use #[once]
attribute. rstest
call your fixture function just once and
return a reference to your function result to all your tests:
Local lifetime and #[by_ref]
attribute
In some cases you may want to use a local lifetime for some arguments of your test.
In these cases you can use the #[by_ref]
attribute then use the reference instead
the value.
You can use #[by_ref]
attribute for all arguments of your test and not just for fixture
but also for cases, values and files.
Complete Example
All these features can be used together with a mixture of fixture variables, fixed cases and a bunch of values. For instance, you might need two test cases which test for panics, one for a logged-in user and one for a guest user.
use *;
// We can use `fixture` also as standard function
// We can give a name to every case : `guest` in this case
// and `authorized_user`
// We would test a panic
This example will generate exactly 6 tests grouped by 2 different cases:
running 6 tests
test should_be_invalid_query_error::case_1_authorized_user::query_1_____ - should panic ... ok
test should_be_invalid_query_error::case_2_guest::query_2_____someinvalid_chars__ - should panic ... ok
test should_be_invalid_query_error::case_1_authorized_user::query_2_____someinvalid_chars__ - should panic ... ok
test should_be_invalid_query_error::case_2_guest::query_3____n_o_d_o_t_s___ - should panic ... ok
test should_be_invalid_query_error::case_1_authorized_user::query_3____n_o_d_o_t_s___ - should panic ... ok
test should_be_invalid_query_error::case_2_guest::query_1_____ - should panic ... ok
test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Note that the names of the values try to convert the input expression in a Rust valid identifier name to help you find which tests fail.
More
Is that all? Not quite yet!
A fixture can be injected by another fixture, and they can be called using just some of its arguments.
As you noted you can provide default values without the need of a fixture to define it.
Finally, if you need tracing the input values you can just
add the trace
attribute to your test to enable the dump of all input
variables.
//This attribute enable tracing
running 2 tests
test should_fail::case_1 ... FAILED
test should_fail::case_2 ... FAILED
failures:
---- should_fail::case_1 stdout ----
------------ TEST ARGUMENTS ------------
number = 42
name = "FortyTwo"
tuple = ("minus twelve", -12)
-------------- TEST START --------------
thread 'should_fail::case_1' panicked at 'assertion failed: false', src/main.rs:64:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
---- should_fail::case_2 stdout ----
------------ TEST ARGUMENTS ------------
number = 24
name = "TwentyFour"
tuple = ("minus twentyfour", -24)
-------------- TEST START --------------
thread 'should_fail::case_2' panicked at 'assertion failed: false', src/main.rs:64:5
failures:
should_fail::case_1
should_fail::case_2
test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out
In case one or more variables don't implement the Debug
trait, an error
is raised, but it's also possible to exclude a variable using the
#[notrace]
argument attribute.
You can learn more on Docs and find more examples in
tests/resources
directory.
Rust version compatibility
The minimum supported Rust version is 1.67.1.
Changelog
See CHANGELOG.md
License
Licensed under either of
-
Apache License, Version 2.0, (LICENSE-APACHE or license-apache-link)
-
MIT license LICENSE-MIT or license-MIT-link at your option.